Hello We released the 0.11.0 exactly 3 months ago. And here we are, 3 months later, still far from the stable release. Our estimate is still the same: just one more month until the stable. There are more reasons of this: It looks like the new wave of people coming to Factorio discovered many new problems. Many of these were in the game from the very early stage, but just haven't been detected until now. All the code written until 0.11 (2 and half years of work) needs to work in strictly deterministic manner now for the multiplayer. We started to cover all of the bugged areas by automated tests. Sometimes it takes 5 minutes to fix the bug, but another 2 hours to make the correct test for it. I hope it will pay off in the future. And last, but not least, lot of bugs have this kind of life-cycle:
Hello, it has been long, but successful week, mainly because we gave our first tax returns containing Factorio earnings while keeping mental health intact, hopefully. As celebration of the 2^13 copies we are about to approach I made a Factorio version of the game everyone is playing now , the time you can spend on it should justify the shorter length of this text :) Apart playing 2048 we managed to make 2 bugfix releases this weak just to find out, there are still some small bugs left, but the version is close to be stable for sure. So we sit down and it took us few short minutes to write down the roadmap that will take us almost the rest of this year to finish. There are many smaller things on the way, but these are the milestones we would like to aim for. What we are still unsure about is when to try to hit the steam+bigger exposure button. I just read my post on the steam from half a year ago, where we stated, that when 0.6 is stable, we will get the trailer and we will apply for steam. Here we are waiting for the 0.9, the trailer almost finished, but still not sure whether we should really start the campaign now. When we start imagining the additions and polishing we have planned for the foreseeable future, the only rational thing that seems to be viable now is to wait for these. We still believe that we have just single shot for the first impression and if we shoot too early for it, we risk to hit our leg. The updated look of the belts We are always eager to learn what you think at our forums.
Hello, this week has been a week of typical bug fixing of 0.16, so development news wise, there is not much to write about. However we have some updates on some other goings on in the company.
Hello, the office has had a very lively atmosphere this week. With some very productive team discussions taking place, we reach another Friday with an optimistic outlook of the weeks to come.
Hello time is flying by and we have started some serious preparations for the Steam release. Martin and Kuba are making sure that we have the Steam compatible builtds as soon as possible. This basically means that out automated build process time will be doubled (the Steam binaries are different because of linkage against Steam libraries). We haven't yet figured if all the experimental updates will go to Steam, or what exactly will be the model, but we are working on that. Albert is wrapping up the new gameplay trailer and based on the testimony of couple of "unbiased" testers you have something to look forward to. The trailer will be released when we launch on Steam. Ondra (Oxyd) has been working hard on the Pathfinder improvements. This time it is mainly connected to how our path cache works. He wrote the following to give you an idea of what he has been up to.
Hello, Rseding has just arrived for another 6 week visit here at the office, and his timing is pretty great as we start shifting the focus onto 0.15, of which our to-do list is extremely long.
Entity info experiments (kovarex) The Entity info is the information about the currently selected entity that appears on the right side of the screen: We had 2 problems with its current state: As it is on the side of the screen, and the entity you are inspecting is generally in the center, it feels cumbersome to move your eyes from the entity to the info and back all the time. As it is always appearing, it adds unnecessary clutter to the screen. It is always blinking there, while 99% of the time it is not really needed. So we experimented with entity info as a tooltip next to the cursor when hovering the entity: So we tested 3 different ways to activate it: It always appears at the cursor, which has the disadvantage of always being in your way in the middle of the screen. It always appears, but it has some delay. It only appears when a hotkey is pressed (we tested it with Shift), which has the disadvantage that you have to actually do something to see it. We assigned each of the options to be tested by someone, with the hope to figure out which (if any) of them is better than the current one. Vaclav tested option 1, Twinsen tested option 2 and I tested option 3. Unfortunately the result was that in the end everyone preferred his option the most, and we had no conclusion at all. Then we realized that the flaw of the test was that each of us picked the kind of option we already knew we would probably like. After some discussions, we decided on the following: The current version of entity info will be the default. We add an option to set a custom delay for it, that is different than the normal tooltip delay (or never). We add an option to activate it with a key. We add an option to have it next to cursor or on the side. Two years ago, I was under the impression, that we need to eradicate all the weird options, to make the game just work for everyone. Over time and after all experience and feedback we have gathered, I started to realize that different people have different expectations, and their brains are wired differently. Some option might be useless for 99% or players, but for the 1% of players, it might be the most annoying thing to be able to customize it.
Hello, another week has passed here, with part of the team still out in Taiwan. They should be back next week, with some news of their great adventure.
New Fluid system 2 (Dominik) Hi Factorians, Here is Dominik, with an update on the fluids. This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features. In FFF-260 I wrote about how it all started, why we are doing it and what the plan is. There was a huge response from you all and I want to thank everyone for their contributions. Let me apologise to redditors, as at the beginning I started responding on the forums and when I realized there is reddit too, there were too many comments for me to handle. The forum users produced many ideas on how the system could work. About third of them was a fluid teleportation, many where known but many were entirely new and interesting. What intrigued me was the large variety of backgrounds they came from - differents kinds of engineers (mechanical, CS, electrical, ...), mathematicians, physicists, and even people with real pipes hands on experience. I won’t go through them here, you can find them on the forums or reddit. There were two proposals on the forum though that were so good that they made it into the game - from quinor and TheYeast. Both of these proposals were very similar and kinda similar to the previous game logic. What it shares is that the mechanic still uses fluid physics simulation and volume in a pipe as a base for the movement calculation. As a result, not much changes on the first glance. What they add though is an emphasis on the fluid network update being independent on the current state (i.e. updating one pipe only depends on state from the last tick) and is therefore independent on evaluation order, which was one of the big pains of the old model that led to sometimes ridiculous junction behavior. Difference between these two was rather small - quinor’s version allowed perfect throughput with 3 passes over the fluidboxes (fluidbox is the thing managing fluids for entities, so I will talk about them), while Yeast’s one was 2 pass with ¼ throughput. What was outstanding though is that TheYeast, a physicist, supported the model with a nice theoretical background and what’s more, he made an amazing JS simulator to test and compare various modification of the model. Because that extra pass in quinor’s version was too high a price for the perfect throughput, I went with TheYeast’s two pass one. Since the old algorithm only used a single pass run by entities for the update, I first needed to overhaul the whole system to allow accommodating the new one. Going from one pass to two passes necessarily means higher complexity, so we made a big effort to optimize everything we could to make sure we will still end up faster than 0.16. Kovarex wrote about it in FFF-271.
